Mtc key management for sending key from network to ue

ABSTRACT

A root key (K_iwf) is derived at a network and sent to MTC UE (10). The K_iwf is used for deriving subkeys for protecting communication between MTC UE (10) and MTC-IWF (20). In a case where HSS (30) derives the K_iwf, HSS (30) send to MTC-IWF (20) the K_iwf in a new message (Update Subscriber Information). In a case where MME (40) derives the K_iwf, MME (40) sends the K_iwf through HSS (30) or directly to MTC-IWF (20). MTC-IWF (20) can derive the K_iwf itself. The K_iwf is sent through MME (40) to MTC UE (10) by use of a NAS SMC or Attach Accept message, or sent from MTC-IWF (20) directly to MTC UE (10). In a case where the K_iwf is sent from MME (40), MME (40) receives the K_iwf from HSS (30) in an Authentication Data Response message, or from MTC-IWF (20) directly.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation application of U.S. patentapplication Ser. No. 16/505,060 filed on Jul. 8, 2019, which is acontinuation application of U.S. patent application Ser. No. 14/646,523filed on May 21, 2015, which is issued as U.S. Pat. No. 10,412,579,which is a National Stage Entry of international applicationPCT/JP2013/007092 filed on Dec. 3, 2013, which claims the benefit ofpriority from Japanese Patent Application No. 2012-267256 filed on Dec.6, 2012, the disclosures of all of which are incorporated in theirentirety by reference herein.

TECHNICAL FIELD

The present invention relates to key management in MTC (Machine-TypeCommunication) system, in particular to a technique to send a key from anetwork to a MTC UE (User Equipment), for securing communication betweenan MTC-IWF (MTC Inter-Working Function) and the MTC UE.

BACKGROUND ART

As described in NPL 1, the security over the interface between an MTCdevice and an MTC-IWF should be studied. Note that the MTC Device is aUE equipped for MTC, which will be sometimes referred to as “MTC UE” or“UE” in the following explanation.

CITATION LIST Non Patent Literature

-   NPL 1: 3GPP TR 33.868, “Security aspects of Machine-Type and other    Mobile Data Applications Communications Enhancements; (Release 12)”,    V0.10.0, 2012-09-   NPL 2: 3GPP TR 23.887, “Machine-Type and other Mobile Data    Applications Communications Enhancements (Release 12)”, V0.3.0,    2012-10

SUMMARY OF INVENTION Technical Problem

However, in 3GPP (3rd Generation Partnership Project), the study has notbeen fulfilled. Therefore, secure communication solution is requiredbetween an MTC device and an MTC-IWF.

Accordingly, an exemplary object of the present invention is to ensuresecure communication between an MTC device and an MTC-IWF.

Solution to Problem

In order to achieve the above-mentioned object, this invention dealswith the following issues:

How the root key K_iwf is derived at network and being sent to UE.

This invention provides the solution of network deriving the root keyK_iwf for secure communication purpose between UE and MTC-IWF andsending K_iwf to UE. Note that the network here means the network nodewhich derives key K_iwf. There are multiple options for which networknode to derive key K_iwf. This applies to the description through thisinvention.

Advantageous Effects of Invention

According to the present invention, it is possible to solve theabove-mentioned problems, and thus to ensure secure communicationbetween an MTC device and an MTC-IWF.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a configuration example of acommunication system according to an exemplary embodiment of the presentinvention.

FIG. 2 is a sequence diagram showing an operation example of key sendingto UE when communication initiated by UE, in the communication systemaccording to the exemplary embodiment.

FIG. 3 is a sequence diagram showing an operation example of key sendingto UE when communication initiated by trigger, in the communicationsystem according to the exemplary embodiment.

FIG. 4 is a block diagram showing a configuration example of a firstnetwork node according to the exemplary embodiment.

FIG. 5 is a block diagram showing a configuration example of a secondnetwork node according to the exemplary embodiment.

FIG. 6 is a block diagram showing a configuration example of a thirdnetwork node according to the exemplary embodiment.

DESCRIPTION OF EMBODIMENTS

Hereinafter, an exemplary embodiment of the present invention will bedescribed with the accompany drawings.

As shown in FIG. 1, a communication system according to this exemplaryembodiment includes a core network (3GPP network), and one or more MTCUEs 10 which are UEs equipped for MTC and connect to the core networkthrough a RAN (Radio Access Network). While the illustration is omitted,the RAN is formed by a plurality of base stations (i.e., eNBs (evolvedNode Bs)).

The MTC UE 10 attaches to the core network. The MTC UE 10 can host oneor multiple MTC Applications. The corresponding MTC Applications in theexternal network are hosted on an SCS (Service Capability Server) 50.The SCS 50 connects to the core network to communicate with the MTC UE10.

Further, the core network includes an MTC-IWF 20 as one of its networknodes. The MTC-IWF 20 serves as a gateway to the core network for theSCS 50. The MTC-IWF 20 relays messages between the MTC UE 10 and the SCS50. The core network includes, as other network nodes, an HSS (HomeSubscriber Server) 30, an MME (Mobility Management Entity), an SGSN(Serving GPRS (General Packet Radio Service) Support Node), an MSC(Mobile Switching Centre) and the like. In the following description,the MME, SGSN and MSC are sometimes referred to as “MME/SGSN/MSC”, andcollectively or individually denoted by the symbol 40. Communicationbetween the MTC UE 10 and the MTC-IWF 20 is conducted through theMME/SGSN/MSC 40.

Next, operation examples of this exemplary embodiment will be describedin detail with reference to FIGS. 2 and 3.

1. Initialization (Key Provision)

There are three options for which network node to derive the root keyK_iwf, i.e., HSS 30, MME/SGSN/MSC 40 or MTC-IWF 20.

Thereafter there are three ways of how key K_iwf is provided to MTC-IWF20.

1) HSS 30 derives the root key K_iwf and sends it to MTC-IWF 20 in forexample Subscriber Information Response (described in NPL 2), or a newmessage which is called Update Subscriber Information. The K_iwf sendingis after AKA (Authentication and Key Management) procedure with UE 10 issuccessfully completed. K_iwf is also sent to MME 40 in AuthenticationData Response for example, such that MME 40 later can send it to UE 10.Note that in the following explanation, description as to the MME issimilarly applied to the SGSN and the MSC.

2) MME 40 derives the root key K_iwf and sends it to MTC-IWF 20 via HSS30 or directly with a new message (for example Report message includingreport.type=“UE is authenticated”, UE ID, K_iwf).

3) MTC-IWF 20 itself derives the root key K_iwf. MTC-IWF 20 sends K_iwfto MME 40 over interface T5 shown in FIG. 1, such that MME 40 later cansend it to UE 10.

Both UE 10 and network (e.g., triggered by SCS 50) can initiate acommunication to the other end. Therefore sending root key K_iwf to UE10 is different in each case. In the following the key sending will bedescribed.

2. Detailed Description of Root Key K_Iwf Sending Procedure <Case 1: UEInitiates Communication>

The root key K_iwf should be derived after HSS 30 verified that the UE10 is allowed to have MTC type communication and authenticated tonetwork. K_iwf can be sent to UE 10 during the first Attach procedure oronce the first Attach procedure is completed.

The root key K_iwf can be sent from MME 40 to UE 10 in NAS (Non AccessStratum) SMC (Security Mode Command) or Attach Accept message, when NASsecurity confidentiality is started. When K_iwf is sent in NAS SMCmessage, it should be protected by NAS confidentiality key. When K_iwfis sent in Attach Accept message, the key itself does not needprotection when the Attach Accept message is confidentially protectedwith NAS security context. MME 40 can either derive K_iwf itself orreceive it from HSS 30 or MTC-IWF 20 as described above.

The details are shown in FIG. 2.

Step S1: Secure communication is established between the network nodes,MME/SGSN/MSC 40, HSS 30 and MTC-IWF 20.

Step S2: UE 10 sends Attach Request to MME 40 with UE capability showingit is MTC type UE.

Step S3: The standard AKA procedure can be started.

Step S4: According to the UE capability, HSS 30 verifies if the UE 10 isa MTC device and if it is allowed to communicate with MTC-IWF 20. If theverification is successfully completed, the key derivation and sendingwill be carried out.

Steps S5 to S7: In case that the HSS 30 derives root key K_iwf, it sendsthe key to MTC-IWF 20 in a new message which can be called “UpdateSubscriber Information” with UE capabilities included. Meanwhile, itsends K_iwf to MME 40 in Authentication Data Response message.

Steps S8 to S11: In case that MME 40 derives the root key K_iwf, HSS 30sends the parameter (if necessary) in Authentication Data Responsemessage to MME 40. After MME 40 derived K_iwf, it can send it to MTC-IWF20 in two ways.

One (steps S10 a and S10 b) is that MME 40 sends K_iwf in a new messageto HSS 30, then HSS 30 sends it to MTC-IWF 20 in a new message calledUpdate Subscriber Information message.

The other way (step S11) is that MME 40 directly sends K_iwf overinterface T5 in a new message or in a Report message to MTC-IWF 20.

Steps S12 to S14: In case that MTC-IWF 20 derives the root key K_iwf,HSS 30 sends the key derivation parameters if necessary in a new messagecalled Update Subscriber Information. After MTC-IWF 20 derived K_iwf, itsends K_iwf to MME 40 over interface T5 in a new message.

Step S15: MME 40 sends the root key K_iwf in either NAS SMC, with K_iwfencrypted by NAS security context or Attach Accept message withconfidentiality security.

<Case 2: Communications Initiated by Trigger>

In the same way, the key K_iwf is derived at network and it is sent tothe UE 10. Either the key itself or the required key derivationparameter is sent to the MTC-IWF 20.

The details are shown in FIG. 3.

Step S21: The secure communication is established between HSS 30 andMTC-IWF 20.

Step S22: SCS 50 sends a MTC device trigger to MTC-IWF 20, containingthe UE ID it triggers.

Step S23: MTC-IWF 20 sends Subscriber Information Request message to HSS30, including message type as trigger and the UE ID.

Step S24: Authentication with UE 10 is carried if UE 10 has not beenauthenticated yet.

Steps S25 to S27: When the HSS 30 derives root key K_iwf, it sends thekey to MTC-IWF 20 in Subscriber Information Response message. Meanwhile,it sends K_iwf to MME 40 in Authentication Data Response message.

Steps S8 to S11: This procedure is the same with Case 1.

Step S31: In case that MTC-IWF 20 derives the root key K_iwf, HSS 30sends the key derivation parameters if necessary in SubscriberInformation Response message. After MTC-IWF 20 derived K_iwf, it sendsK_iwf to MME 40 over interface T5 in a new message.

Steps S13 to S15: This procedure is the same with Case 1.

Note that in steps S6, S10 and S12 of Case 1, Update SubscriberInformation is used as an example of a new message. HSS 30 can also waittill next Subscriber Information Request received from MTC-IWF 20 thenit can send K_iwf in Subscriber Information Response message.

HSS 30 can have the key derivation parameter installed or receives itfrom MTC-IWF 20. MME 40 can also receive the key derivation parameterfrom MTC-IWF 20 instead of HSS 30.

Alternatively, MTC-IWF 20 can send K_iwf directly to UE 10. In this caseK_iwf does not need to be sent to MME 40, thus Steps S7, S15 and S27 arenot needed.

Alternatively, MTC-IWF 20 can derive and send K_iwf to HSS 30 beforeeven AKA procedure started and HSS 30 can send K_iwf to UE 10 once it isauthenticated.

Network can alternatively send the subkeys to UE 10 instead of sendingthe root key. In this case, UE 10 does not need to derive the sub keysat its side which will be described later. This has less impact to UEbut on the other hand increase signaling with network.

Since a UE may not be allowed to communicate with MTC-IWF (not a MTCdevice) or an UE may not request communication with MTC-IWF, the new keyhierarchy should not be established in such cases.

3. Subkey and Message Protection

When UE 10 and MTC-IWF 20 have the root key K_iwf they can derivesubkeys K_di_conf and K_di_int. The subkey K_di_conf is aconfidentiality key for encrypting and decrypting messages transferredbetween the MTC UE 10 and the MTC-IWF 20. The subkey K_di_int is anintegrity key for checking the integrity of messages transferred betweenthe MTC UE 10 and the MTC-IWF 20. The communication between UE 10 andMTC-IWF 20 should be both confidentiality and integrity protected by thesub keys.

When MTC-IWF 20 receives a message from UE 10 which is protected by adifferent key that MTC-IWF 20 holds, it should discard the message. s anoption it can inform HSS 30, such that HSS 30 can take on proper actionfor example key renew procedure, UE re-authentication or detach.

When UE 10 receives a message from MTC-IWF 20 which is protected by adifferent key that UE 10 holds, it can request for a new key.

Next, configuration examples of the MTC-IWF 20, the HSS 30 and theMME/SGSN/MSC 40 according to this exemplary embodiment will be describedwith reference to FIGS. 4 to 6. Note that in the following explanation,there will be described only elements which are specific to thisexemplary embodiment. However, it will be understood that the MTC-IWF20, the HSS 30 and the MME/SGSN/MSC 40 also include elements forfunctioning as typical MTC-IWF, HSS and MME/SGSN/MSC, respectively.

As shown in FIG. 4, the MTC-IWF 20 includes at least one of a receptionunit 21 and a send unit 22. In the case where the HSS 30 or theMME/SGSN/MSC 40 derives the root key K_iwf, the reception unit 21receives the root key K_iwf directly from the MME/SGSN/MSC 40, orthrough the HSS 30 as shown at steps S6, S10 and S11 in FIG. 2, andshown at step S26 in FIG. 3. The send unit 22 can send the keyderivation parameters to the HSS 30 or the MME/SGSN/MSC 40. Moreover,the send unit 22 can send the root key K_iwf directly to the MEC UE 10.Note that these units 21 and 22 are mutually connected with each otherthrough a bus or the like. These units 21 and 22 can be configured by,for example, transceivers which respectively conduct communication withthe HSS 30 and the MME/SGSN/MSC 40, and a controller such as a CPU(Central Processing Unit) which controls these transceivers.

As shown in FIG. 5, the HSS 30 includes at least one of a determinationunit 31 and a send unit 32. The determination unit 31 performs theverification as shown at step S4 in FIG. 2. In the case where the HSS 30derives the root key K_iwf, the send unit 32 sends the root key K_iwf tothe MTC-IWF 20 and the MME/SGSN/MSC 40 as shown at steps S6 and S7 inFIG. 2, and shown at steps S26 and S27 in FIG. 3. On the other hand, inthe case where the MTC-IWF 20 or the MME/SGSN/MSC 40 derives the rootkey K_iwf, the send unit 32 can send the key derivation parameters tothe MTC-IWF 20 or the MME/SGSN/MSC 40 as shown at steps S8 and S12 inFIG. 2, and shown at step S31 in FIG. 3. Note that these units 31 and 32are mutually connected with each other through a bus or the like. Theseunits 31 and 32 can be configured by, for example, transceivers whichrespectively conduct communication with the MTC-IWF 20 and theMME/SGSN/MSC 40, and a controller such as a CPU which controls thesetransceivers.

As shown in FIG. 6, the MME/SGSN/MSC 40 includes a send unit 41. Thesend unit 31 sends the root key K_iwf to the MTC UE 10 as shown at stepS15 in respective FIGS. 2 and 4. In the case where the MME/SGSN/MSC 40derives the root key K_iwf, the send unit 31 sends the root key K_iwfdirectly to the MTC-IWF 20, or through the HSS 30 as shown at steps S10and S11 in respective FIGS. 2 and 3. This send unit 31 can be configuredby, for example, transceivers which respectively conduct communicationwith the MTC UE 10, the MTC-IWF 20 and the HSS 30, and a controller suchas a CPU which controls these transceivers.

Note that the present invention is not limited to the above-mentionedexemplary embodiment, and it is obvious that various modifications canbe made by those of ordinary skill in the art based on the recitation ofthe claims.

The whole or part of the exemplary embodiment disclosed above can bedescribed as, but not limited to, the following supplementary notes.

(Supplementary Note 1)

Network determines whether UE can have MTC communication and K_iwf canonly be sent to MTC type UE.

(Supplementary Note 2)

MME sends K_iwf to UE in NAS SMC or Attach Accept message, and sends thekey to MTC-IWF over T5 interface for example in Report message; orthrough HSS in Subscriber Information Response message or a new message“Update Subscriber Information”.

(Supplementary Note 3)

HSS derives the key K_iwf and sends it to UE through MME, and sends thekey to MTC-IWF in Subscriber Response message or a new message “UpdateSubscriber Information”.

(Supplementary Note 4)

MTC-IWF derives the key K_iwf. After the derivation or receiving if fromHSS or MME, it sends K_iwf to UE through MME or in a direct message.

(Supplementary Note 5)

HSS sends the key derivation parameter to MME in Authentication DataResponse, or alternatively MTC-IWF provides the key derivationparameters to MME.

(Supplementary Note 6)

HSS sends the key derivation parameter to MTC-IWF in SubscriberInformation Response message or a new message “Update SubscriberInformation”, or alternatively MTC-IWF provides the key derivationparameter to HSS.

This application is based upon and claims the benefit of priority fromJapanese patent application No. 2012-267256, filed on Dec. 6, 2012, thedisclosure of which is incorporated herein in its entirety by reference.

REFERENCE SIGNS LIST

-   10 MTC UE-   20 MTC-IWF-   21 RECEPTION UNIT-   22, 32, 41 SEND UNIT-   30 HSS-   31 DETERMINATION UNIT-   40 MME/SGSN/MSC-   50 SCS

1. A first network node comprising: at least one processor; and at leastone memory coupled to the at least one processor, the at least onememory storing instructions that when executed by the at least oneprocessor, cause the at least one processor to: receive, from a UserEquipment (UE), a first message including capability informationindicating that the UE is enabled for a service related to Machine TypeCommunication (MTC), send a second message to the UE, wherein the UEderives an encryption key, receive, from a third network node, a thirdmessage including key information related to derivation of a first key,derive the first key based on the key information, and send a fourthmessage including the first key to a second network node that derivesthe encryption key from the first key, wherein the second network nodedecrypts, by using the encryption key, messages passed between the UEand the second network node via the first network node.
 2. A method of afirst network node, the method comprising: receiving, from a UserEquipment (UE), a first message including capability informationindicating that the UE is enabled for a service related to Machine TypeCommunication (MTC); sending a second message to the UE, wherein the UEderives an encryption key; receiving, from a third network node, a thirdmessage including key information related to derivation of a first key;deriving the first key based on the key information; and sending afourth message including the first key to a second network node thatderives the encryption key from the first key, wherein the secondnetwork node decrypts, by using the encryption key, messages passedbetween the UE and the second network node via the first network node.3. A second network node comprising: at least one processor; and atleast one memory coupled to the at least one processor, the at least onememory storing instructions that when executed by the at least oneprocessor, cause the at least one processor to: receive a first key froma first network node, wherein the first network node receives, from aUser Equipment (UE), a message including capability informationindicating that the UE is enabled for a service related to Machine TypeCommunication (MTC), derive an encryption key from the first key, anddecrypt, by using the encryption key, messages passed between the UE andthe second network node via the first network node.
 4. A method of asecond network node, the method comprising: receiving a first key from afirst network node, wherein the first network node receives, from a UserEquipment (UE), a message including capability information indicatingthat the UE is enabled for a service related to Machine TypeCommunication (MTC); deriving an encryption key from the first key; anddecrypting, by using the encryption key, messages passed between the UEand the second network node via the first network node.
 5. A UserEquipment (UE) comprising: at least one processor; and at least onememory coupled to the at least one processor, the at least one memorystoring instructions that when executed by the at least one processor,cause the at least one processor to: send, to a first network node, afirst message including capability information indicating that the UE isenabled for a service related to Machine Type Communication (MTC),receive a second message from the first network node, derive anencryption key based on receipt of the second message, and encrypt,using the encryption key, messages passed between the UE and a secondnetwork node via the first network node.
 6. A method of a User Equipment(UE), the method comprising: sending, to a first network node, a firstmessage including capability information indicating that the UE isenabled for a service related to Machine Type Communication (MTC);receiving a second message from the first network node; deriving anencryption key based on receipt of the second message; and encrypting,using the encryption key, messages passed between the UE and a secondnetwork node via the first network node.